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INTRODUCTION 


This memorandum discusses the use of demountable ftogical 
volumes in the new storage system. MIB-110 (Implementation of 
Proposed New Storage System) cescribes how, In the new storage 
system, the Multics hnlerarchy is divided into logical volumes, 
that may consist of part of a physical volumes. or several 
physical volumese A physical volume may contain storage for only 
one logical volume. All physical votumes that comprise a logical 
volume must be mounted or demounted at the same time. Thus a 
logical vosjume may not be partially mounted. Logical volumes can 
be mounted or demounted while the system is running. 


A special tlogicalt volume, the Root Logical Volume (RLV), 
cannot be demountede Except during the booting the system all of 
the packs that make up the RLV are mounted. The RLV corresponds 
to the Multics storage system as we know if today. It is in the 
use of daogical volumes other than the RLV that the new storage 
system provides new user interfaces. This memorandum presents an 
overview of several new concepts that are involved with the use 
of demountabie logical volumes. Future MT&s will be pubtished 
that discuss these new concepts in detail!. The main new concepts 
are? 


- registration of foglcal volumes 
- master directories 


- mounting ftogical volumes 


REGISTRATION OF LOGICAL VOLUMES 


Tne registration of volumes is a concept trat has been 
discussed before, for exampie In MT8-976 (The Tape Mount 
Package). The registration of tape reeis and disk packs Ils 
pianned as ae future extension to the Resource Control] Package 
(RCP). The use of logical volumes In the new storage sysfem 
requires that the mechanism for registering these logical voiumes 
be implemented nowe 
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The registration of a iogical volume impiies that the system 
maintaln data about this fogical volume. This data wlil be kept 
in a fille calted the Logical Volume Registration Ejite (LVRF). An 
entry in the LVRF will! be malntained for each togical votume. 
The LVRF wl!!! be focated in some permanent system directory that 
is on the RLV. The LVRF wlll nave ring brackets. of 1» is te 
Access to the LVRF willl be Reag for ali users and Read-Write for 
those privlieged users that may act as volume Iibrarlans. 


Alt of the data needed to malntain the directories or 3 
logical volume and ail of the data needea to mount a togical 
volume wlll be kept directty or Indirectly in tre LVRF entry for 
the logical volume. This data includes? 


A list of the physical packs that comprise this togical 
volume. Also, for each packs information needed to 
mount the pack will! be kept. 


- The pathname of the Master Olrectory Control Flle that 
is used to malntain the directories on this togica!l 
volume. Master directory control fites are discussed 
In the next section. 


- The pathname of an Access Control Segment that controls 
access to the togical volume. 


- PDefauit access to this logical volume when no Access 
Control Segment is avallable.e 


- Information about the owner of the toglcal volume. 
The concept of Access Control Segments (ACS) was Introduced 


in MTB-184 (Tne Resource Controt Package). An ACS is a zero 
fength segment whose ACL is used to control access fo some 


resource. In this case the resource Is a togicai volume. The 
pathname of the ACS for a togicali volume is specified by the 
owner of the ftogical volume during volume registration. It can 


be changed oniy by votume ftibrarlans.e. The tocation and ring 
brackets of the ACS are entirety under the control of the owner 
of the loglcal volume. Tre owner of the logical votume Is 
responsible for creating the ACS, creating any tinks to Its and 
setting the ACL to appropriately control access to the togical 
volume. 


Regular ACL commands can be used to set the ACL of a togicat 
volume. The access modes REW will be Interpreted in ring ty 
however, and they have somewhat different meanings for logical 
volumes’ 
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- RW (Read/Write) access 1s needed to mount ae togicat 
volume 


- € (Executive) access is needed to set user quota on a 
logical volume. 


MASTER DIRECTORIES 


In the new storage system ail segments contained in the same 
directory musf be ptaced in the same fiogical voiume. When a 
directory is created, it normaliy inherits the “sons_ivid"’ item 
from its parent directory. A directory whose “sons_Ivid™ is 
different from Its parent is calied a master glrectory. Thus a 
master directory is a directory whose sons reside on a togicali 
volume that Is dlfferent from the logical volume that hotds_ the 
segments of the master directory*s parent. Master directories 
provide the mechanism for placing a plece of the hierarchy on a 
demountable ftogical volume. 


To create a master directory new control arguments must be 
used with the create_dir command. These arguments specify the 
name of the ftogicai volume that the master directory will reside 
on and a quota valuee This Irformation Is passed to a new ring 1 
subsystem calted Master Qicectory Controi (MOC). MDC checks 
access to the toglcait volume and checks quota on the togical 
volume before calling ring 90 to actuaiiy create tre directory. 
An additional privileged caii is mace to the nardcore to set the 
sons_tivid to fhat of the specified ftogical volftume.s. In order to 
create amaster directory a user must have the followlng access? 


- SMA access to the parent directory. This, of course, 
ls checked In ring 0. 


- RW access to the togical volume on which the master 
directory will reside. This check is made by MOC In 
ring ie This access is obtalned from the registration 
data for thls f!ogical voiume. If possible It is taken 
from the ACS for this toglcal volume. Tf no acs 1s 
avaliabie it Is taken from the default access speclfled 
In the LVRF entry for this ftogical voiume. 


- Sufficient quota on the !togical volume for this master 
directory. 


Tne controt of quota in a togicat volume is the main 
function of MOC. Because a disk pack contains so many records, 
it witli be normal for packs to be shared by many users, and for 
there to be many master directorles for a ftogical votume, eacr of 
which is the root of a (posslbiy targe) subtree. The owner of a 
logical voiume will be provideo with the resource-contro! fools 
to allow him to measure and control tne usage of a pack. 
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The owner of a togical volume ras this control by being able 
the specify which users have "E€“" access to the togicat votume. 
Users that have “E" access to a togical volume may act as 
“executives™ for the tiogical volume. An executive for a_togical 
volume can speclfy the totai quota allowed on the togical volume 
for each user and thus can specify which users may create master 
directorles on the togical volume. 


The quota and master directory information for each fogical 
volume is maintalned in a file catied a Master Dicectory Control 
Eiije (tMOCF). There is one MOCF for each Jogica! volume. [If Is 
created by MOC when the toglcal volume is registered. MDCFS are 
created In some permanent system directory that is on that RLV. 


Each MDCF contains two sections. The first sectlon is a 
(lst of the users that have quota on the logicai volume. Both 
the total quota allowed for a user and the quotée that has already 
been used are kept. These values are checked and updated wher a 
master directory is created. The second section is a ilst of the 
master directories that exist on the togical volume. The UIO 
pathname, creator nmamey and quota Is kept for each master 
directory. Once a directory is created It Is almost completely 
tike a non-master directory except that quota moves musf be 
between directories with the same sons_Ivid. 


When a master directory for a ftogicai votume Is deteted, the 
cal! is once again intercepted by MDC, which forwards the call to 
the hardcore. The MOCF second section Is updated to show that 
the master directory nas been deleted, and the time-record 
product for the directory Is saved untit' the end of the 
accounting period when the master directory entry is deleted. 
Volume executives may caiti MOC at any time to tist the 
information about deleted oclrectories. The dynamic usage 
information Is kept In the quota ceits for the directorles whose 
sons go on the togical volume, and so a figure accurate to the 
page-second can be obtalned by a program which walks each subtree 
beginning at a master directory and does not Include master 
directories for other tlogicai volumes. Tools to do this will be 
constructed from the current system*s disk quota accounting 
programse 


Users will see only a few interface charges. New options 
for the create _dilrectory command will! be provided. Ring 1 
entries to MDC for creatirgs deleting, and tisting master 
directorles wlft be provided. A new error code willl be returned 


for hes _$quota_move and hces_$delentry_file if an litegai 
operation on a master directory is attempted. Finally, a new 
command wlll be provided so that a user may Interrogate “ris™ 


entries in the MDCF for a togical volume, to see if ne can create 
a master directory, etc. 
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This quota check Is made by MOC in ring 1. 


MOUNTING LOGICAL HES 


In order to initiate a sSegswent that resides on a logical 
volume the logical volume, iees,y ali cf its physical packs, must 
be mounted. Aiso,s each physical pack must be made useable for 
paging by belng accepted Into the PVT via a calf the ring OQ. 
MTB8-213 «(NSS DISK DEFINITION) describes this process in more 
Getait, and explains how permanent vofumes are mounted 
automaticaily when the system is started up. 


For demountable fogicai voiumes it is not feasible to 
provide demand mounting at segment fauit time. Thus the mounting 
of a togical volume must be the result of an explicit mount 
request. The basic rule for using logical volumes Is3 


In order to initiate a segment that resides ona 
logical volume a user must nave previously issued = an 
expficit request to mount that logical votume. 


This rute impiles that a togical volume may be mounted for 
more than one user at a time. A new RCP command and Interface 
wllt) be provided to “mount™ fogical votumes. This command will 
mount the same logicat vojiume for multiple users at the same 
time. When a user mounts a logical volume, tre ID of the togical 
volume is fisted in some per-process ring 0 data base (probably 
the KST). If a user attempts fo initiate a segment that resides. 
on a togica!l volume not listed in his KST, the initiate wlll fal! 
with a “Logical Volume not Mounted™ error. This is true even if 
the togical volume Is already physically mountec and accepted for 
paginge This rule has two imcortant and useful Implicatlons. 


- The mounted/dismounted status of a segment becomes 
deterministic withir a process. 


- The costs of the resources (disk drives) used by the 
logical volume can be distributed among ali of the user 
that have concurrentiy mounted the logical volume, 


A fogicai volume is a new type of resource known to RCP. 
Logical volumes have characteristics that make dealing with them 
quite different from device resources. The rufe for mounting a 
iogical volume described above impiies that the operation of 
mounting a togical volume Is quite dlfferent from the operation 
of mounting a tapee Compare the RCP scenarlos for these’ two 
types of mounts: 
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For a tape mount? 


- Check to see lf the speclfled tape volume Is aiready 
mounted for any processe If it is then return witr an 


errore 


- Assign a tape device to the requesting orocess. 


The 


user must have access to some appropriate tape device. 
This access is obtained from the ACS for each device. 


- Mount the specifled tape volume. Access to the 
reel would be checked and the label verified. 
access checking operations are not done now. 


- Comptete the attacnment to the tape device § (for 
requesting process. 


For a logical votume mount? 


tape 


Trese 


the 


- Check to see [f the specifled toglcali volume Is already 


mounted for the requesting process. If it is 
return with oo error. 


then 


- Check to see if the caller has the required access to 
mount the togical voiume. <A user must nave RW access 


to the foglcal volume as specifled in the LVRF and 
for this logical volume. 


ACS 


- Check to see if tne logical volume is afready mounted 
for any process. If It is make this Sogical volume 


known for this process by caifting into ring 0 to 
this togical votume in the KST. RCP wlll add 
process to a fist of processes that have mounted 


list 
thls 
this 


fogical volume. This successfully completes the mount 


for this process. 


- If the ftogicat volume is not mounted for any process 


then RCP will mount ite RCP wild physicality mount 
pack that comprises this togical volume. RCP 
assign an appropriate disk device for each pack. 


each 
wlti 
It 


wlll mount the pack on the drive. It will make the 


pack useable for paging by having It accepted in 


ring 


Oe If any packs of tre fJogical volume cannot be 


mounted then the mount of the togicalt volume wltl 


fall. 


Not onty is the concept of mounting different for a_togical 
volume, but atso the aigorithm for assignment of the packs and 


disk drives used by a flogicait volume Is daifferent from 
assignment of a disk drive for use as an [/0 diske The 
drives used by a mounted logical volume are not asslgned_ to 
process. They are assigned to the “storage system". The 
whose mount request resuits in the actual! mounting cof 
physical packs of the fogica! volume {is just involved 


the 
oisk 
any 
user 
the 
in an 
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accident of fate. It is the fact trat ali user requests fo mount 
a fogical volume ftook the séeme to the user that makes” the 
mounted/dismounted state of a togical volume deterministic. 


A new RCP command ana interface will be provided to 
“demount™ a logical volume. Demounting a fogical volume invotves 
the foliowing steps for RCP3 


- Remove the logical volume name from the cing 0 list of 
logical volumes mourtea for thls process. 


- Remove this process from the iist of crocess that have 
mounted this togica!l volume. 


- If the demount for tne ltogical voiume for this process 
resuits In no process having the togical volume mounted 
then the fogicat volume will be physicatiy demounted. 


- To physicality demourt a logical volume RCP will call 
ring 6g to disable paging on all the physlcat packs of 
tne logical volume. RCP wii then unassign all of fhe 
disk devices used by this logical volume. 


In order to provide compiete security for new storage system 
volumes, a tabei checking mechanism will be provided during tne 
mounting of both storage system packs and I/0 packs. The fabel 
of every pack mounted wilt be checked. For storage system 
voiumess Obviously, the volume fabel must be compietely correct. 
In addition, in order to prevent a user from mounting an I/0 pack 
and writing a counterfeit tabel on it, in the fope that some 
future operator error wlli cause the pack to be mounted Instead 
of a storage system pack, we wil! put information In the tabel of 
each storage system pack fhat is only known to RCP. We will also 
require that any I/70 pack which Is mounted wlll have Its label 
record read. If the iabei ftooks tike a valid tabel, and _ the 
Jjabel claims that the volume mounted is not the volume requested, 
then the volume will not be mounted. This check insures that an 
operator Cannot accidentally mount a storage system pack as an 
I/0 pack3 and thus protects the sforage system from destructlone 
Specla!l functions, such as pack initialization, and orivileged 
users, such as the volume fibrarian, may bypass this check. 


The system"s charging tools wlll not charge for storage on 
demountable packs by the same method used for permanent storage. 
Permanent Storage wll! continue’ toa be controliec by quota and 
charged for by the page-second. For demountable storage, the 
system willi charge for the number of minutes that the pack was 
mounted, just as is done for tapes and for I/0 packs. (This 
facillty may not be avallabie in the initial release.) Since 
Storage system packs are shared, fhe system wiii charge each of 
the users that have mounted a fogicai volume an equal fraction of 
the total per-minute rate. 
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Directories for segments on a private pack will nave quota 
and time-page-products Just iike other directorles, but since 
these data refer to a snare of a different resource they cannot 
be added to the quota or time-page-product data for segments on 
the system*s permanent storage. The owner of a pack wlflf be abie 
to determine the total time-page-product usase of storage on his 
pack, so that he can “retali™ storage space to other users. 


The eventual pian for tne development of RCP inctudes a 
resource-reservation faciilty that wlll allow a user to negotiate 
with the system for future avellability of specifiec combinations 
of resources. Since the number of free disk drives at a site Is 
fikely to be relatively smati and competition for them severe, we 
may need to implement interim measures such as time Jimits on the 
duration of a mount and speclai RCP poticles in order to pernmlt 
installations to make the most effective use of their oalsk 
drives. 


